Alpha Cloud - Alpha Anywhere Developer's Guide
Development/Test/Production Workflow
About Applications and Deployments
Dev/Test/Prod Workflow
Setting Up a Workflow
When Things Go Wrong
About Applications and Deployments
A key concept of Alpha Cloud is that publication and deployment are actually two separate steps. This is important because it gives us a lot of options with respect to how versions of web projects move through development and test and on to production. It also gives us the option of rolling back to a prior version of an application.
Each Application that you create on Alpha Cloud can be thought of as a web project. When you make changes in Alpha Anywhere, you can publish your web project to Alpha Cloud, creating a new version of the application. Nothing is running yet. We have simply prepared the current web project components for deployment and saved a copy on Alpha Cloud with a unique version number. For Application versions to be used, they must be assigned to one or more deployments.
A Deployment is a named object that associates an application with a web site (and potentially a path within that web site) and at a given time, a version of your application, and a build of Alpha Anywhere Application Server for IIS.
You can have any number of deployments associated with an application, each running on a different web site. You could also have multiple deployments assigned to the same web site by using an IIS application path for each. There must be a root application - such as https://www.mysite.com/. Other deployoments can be assigned unique paths within the web site - such as https://www.mysite.com/App1.
Each deployment can be running a different version of your application and a different version of Alpha Anywhere Application Server for IIS.
It is this flexibility that we will use to define a work flow from development through test and on to production.
Dev/Test/Prod Workflow
Each organization has different procedures and policies, but a common way to move from development to production is to set up a work flow where a developer creates and maintains a web project and makes it available for testing prior to moving the web project to production.
On Alpha Cloud, you can do this by creating an application to which a specific web project is published. Remember that publication only prepares files to be deployed and creates a new version of the application, it does not necessarilly deploy them.
A deployment serves as a sandbox. Having a deployment for development and another one for testing and another one for production provides a way for each group to test a different version of the application (web project) at the same time. Each deployment has a unique URL available from anywhere on the web. Note: The default URL for a web site, and therefore a deployment, is generated by Alpha Cloud. Developers and testers can use those generated URLs and the TLS certificate provided for them by Alpha Cloud. There is no need to create a host name and purchase a certificate for each of these deployments.
As a developer finishes changes, they will publish those changes to Alpha Cloud, creating a new version of the application. They may (and probably will) deploy to the Dev deployment at the same time that they publish, so they can verify their changes before declaring them "ready for testing".
The test (or QA) team has a separate Test deployment that they manage to select a version of the application to test.
When an application has been tested, and is ready for production, the Production deployment can be scheduled with the tested version of the application.
For example, we might publish our web project called "MyApp" as:
MyApp (Application)
Dev (Deployment)
Test (Deployment)
Production(Deployment)
So a web project lifecycle is essentially defined by the following steps:
As changes are made, the application is published to Alpha Cloud, creating a new version of the application.
The publish profile also deploys to the Dev deployment so the developer can test on Alpha Cloud.
When a version of the application is ready for testing/validation, you simply schedule the Validation/Test deployment with the appropriate version of the (previously published) application and the Alpha Anywhere build number. No publish happens here.
When a version of the application is validated, you simply schedule the Production deployment with the appropriate version of the application and the Alpha Anywhere build number. No publish happens here either.
Setting Up a Workflow
Although there is no explicit workflow object on Alpha Cloud, we can set up a single application and multiple deployments to provide it. In this example, we are going to set up a deployment for development, a deployment for test (or QA) and a deployment for production.
First, create an application. If you have already published, you have an application already. We can use that. You will typically create an Alpha Cloud web project for each Web Project you create in Alpha Anywhere.
For this example, create three web sites called Dev, Test, and Prod (for development, test, and production, respectively.
Create three deployments and assign them the same names as the web sites (Dev, Test, and Prod respectively).
Note:The web site name and the deployment do not have to match, but it will be easier to keep track of here.
When Things Go Wrong
It is often said that the cost of a bug increases exponentially as it moves further from the developer. Having a Dev/Test/Production workflow certainly reduces the number of such bugs, but issues will still be missed.
If a problem shows up in testing, it is simply a matter of reporting the problem to development.
The developer diagnoses, addresses the issue and then publishes a new version of the application to Alpha Cloud.
The Dev deployment allows the developer to retest in the cloud.
The test team can then "pull" the new version to the Test deployment and retest.
And, of course, some issues make it all the way through test and end up on a production deployment. By now, you may have guessed that the process is similar for production, but there is one more thing we can do. We can roll back the production deployment.
If a problem shows up in production and needs to be addressed immediately, you can roll back to a prior version of the application. You do this by scheduling your deployment and selecting the last working version of the application in the new schedule.
Here's how the process works:
Rollback the changes, as described above, by adding a new schedule line to the deployment with the last good application version.
Development diagnoses and addresses the issue, publishing and testing a new version of the application in the Dev deployment.
Test verifies that the issue is addressed, and judiciously adds a new test to their suite to make sure there are no future regressions.
Move the new application version to production by scheduling the new version.
You may have a different work flow you want to implement. How you use deployments is up to you. You may also choose to have additional and separate deployments for different production groups, or customers.
As we have seen, the separation of publication and deployment gives you a great deal of flexibility.